---
title: "Overview"
description: "Odigos will automatically apply instrumentation to your selected workloads to record observability signals from your services such as collecting traces, metrics, and logs without any code changes."
sidebarTitle: "Overview"
icon: "house"
---

import { LanguagesCard } from "/snippets/languages-card.mdx";

## Supported Runtimes

Odigos provides automatic instrumentations for the following runtimes:

<LanguagesCard
  golangUrl="/instrumentations/golang/ebpf"
  golangDescription="Versions 1.17 and above are supported"
  javascriptUrl="/instrumentations/nodejs/native"
  javascriptDescription="Versions 14 and above are supported"
  pythonUrl="/instrumentations/python/native"
  pythonDescription="Versions 3.8 and above are supported"
  javaUrl="/instrumentations/java/native"
  javaDescription="Versions 8 and above are supported"
  phpUrl="/instrumentations/php/native"
  phpDescription="Versions 8.0.0 - 8.4.x are supported"
  rubyUrl="/instrumentations/ruby/native"
  rubyDescription="Versions 3.1.0 - 3.5.x are supported"
  dotnetUrl="/instrumentations/dotnet/native"
  dotnetDescription="Versions 4.6.2 and above are supported"
/>

## Enrich with OpenTelemetry APIs

Odigos automatically generates data for open-source libraries and frameworks.
Additional trace spans, metrics datapoints and log records can be added using the OpenTelemetry APIs.
Odigos will automatically capture this data and deliver it to the chosen [destination](/backends-overview) alongside the automatically generated data.

<Note>
  No need to configure the OpenTelemetry SDK, Odigos will automatically
  configure it for you.
</Note>

Select a language to learn how to enrich your data with OpenTelemetry APIs:

<LanguagesCard
  golangUrl="/instrumentations/golang/enrichment"
  golangDescription="For applications written in Go"
  javascriptUrl="/instrumentations/nodejs/enrichment"
  javascriptDescription=" For applications written in JavaScript or Node.js"
  pythonUrl="/instrumentations/python/enrichment"
  pythonDescription="For applications written in Python"
  javaUrl="/instrumentations/java/enrichment"
  javaDescription="For applications written in Java or JVM-based languages"
  dotnetUrl="/instrumentations/dotnet/enrichment"
  dotnetDescription="For applications written in C# or .NET"
  phpUrl="/instrumentations/php/enrichment"
  phpDescription="For applications written in PHP"
  rubyUrl="/instrumentations/ruby/enrichment"
  rubyDescription="For applications written in Ruby"
/>

## Instrumentation Flow:

1. User selects a workload to auto instrument by creating a `Source` object (per workload or per namespace).
2. Odigos `instrumentor` component watches for changes with `Source` objects, and creates a relative `InstrumentationConfig` object.
3. Odigos `odiglet` component watches for changes with the `InstrumentationConfig` objects, and runs a runtime inspection on running pods to detect the programming language for every container.
4. Odigos `instrumentor` component watches for changes with the `InstrumentationConfig` object, and adds a resource request into each pod spec of all relevant containers in the workload manifest. These resource requests are called `Instrumentation Devices`.
5. Kubernetes detects the changes in the manifest, and rollout-restarts the pods with the new `Instrumentation Devices`.
6. New pods are scheduled and started. Odiglet resolves the resource request by mounting the auto instrumentation code and relevant environment variables into the container.
7. The auto instrumentation code starts the OpenTelemetry SDK and sends telemetry data to the odigos pipeline.

In case of a failure to instrument a workload, Odigos will disable the instrumentation and rollback the workload, This behaviour can be disabled by running `bash odigos config set rollback-disabled true` or via the helm chart `autoRollback.disabled=false`
